Policy management for data migration

ABSTRACT

A customer of a resource provider environment can apply policies at the data object level that will live with a data object during its lifecycle, even as the object moves across trusted boundaries. A customer can classify data, causing tags and/or predicates to be applied to the corresponding data object. Each tag corresponds to a policy, with predicates relating to various actions that can be performed on the data. A chain of custody is maintained for each data object, such that any changes to the object, tags, or policies for the data can be determined, as may be required for various audit processes. The support of such policies also enables the resource provider environment to function as an intermediary, whereby a third party can receive the data along with the tags, policies, and chain of custody as long as the environment trusts the third party to receive the data object.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit or priority and is a continuation ofallowed U.S. application Ser. No. 14/863,804, filed Sep. 24, 2015,entitled “POLICY MANAGEMENT FOR DATA MIGRATION,” the disclosure of whichis incorporated by reference in its entirety herein for all intents andpurposes.

BACKGROUND

Users are increasingly causing data to be stored in resourceenvironments offered by various resource providers, those environmentsoften referred to as part of “the cloud.” This has many advantages, asusers such as enterprise users are looking to hybrid storage systemsthat combine their existing on-premises storage solutions with theagility of the cloud in order to meet their dynamic business needs. Theuser often will have policies regarding how data is stored and managedwithin the user environment, and a resource provider will often havedifferent policies for data storage and management in their environment.Use policies are typically enforced at the on-premises storage devicesthemselves, and migrating at least some of this data to the cloud addsthe complication that conventional approaches do not also allow formigration and enforcement of the accompanying user policies. In manyinstances the cloud storage environment will not have a mechanism formapping or translating the user policies to the policies supported inthe cloud storage environment.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 illustrates an example environment in which various embodimentscan be implemented.

FIG. 2 illustrates an example environment where policy import/exportengines can enable the management of policies for data migration betweena user environment and a resource provider environment that can beutilized in accordance with various embodiments.

FIG. 3 illustrates an example environment where the resource providerenvironment can function as an intermediary for data transmitted betweena first customer environment and a second customer environment that canbe utilized in accordance with various embodiments.

FIGS. 4A, 4B, and 4C illustrate portions of an example process forapplying policies to a data object that can be utilized in accordancewith various embodiments.

FIG. 5 illustrates an example process for decrypting a data object thatcan be utilized in accordance with various embodiments.

FIG. 6 illustrates example components of a computing device that can beused to implement aspects of various embodiments.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Approaches described and suggested herein relate to the management ofaccess and actions with respect to data stored in various environments.In at least some embodiments, tags can be applied at the data objectlevel, where the tags are each associated with a policy written withrespect to access and use of the data, such as who can access the data,where the data can be accessed, and how the data can be utilized. Thesetags can be tied to a data object throughout its lifetime, even as thedata is moved between locations within an environment or betweenenvironments (i.e., into the cloud), where the data is transmittedacross at least one trust boundary. The tags can be immutable ormutable, where mutable tags are only modifiable by certain trusted andauthorized entities. The tags can be automatically generated or assignedbased on predicates (i.e., filename, date, other metadata) that isapplied to the files and/or policies during communication to the remotestorage system. An envelope that describes the policy can also beassociated with the data object and communicated with it to the cloudstorage system, which for example can allow a deny of a PUT of a dataobject that violates a different policy associated with the bucket (orother repository) receiving the policy at the cloud storage system. Suchuse of policies can allow a cloud storage system or service to become atrusted intermediary for policies, whereby the service can attempt toenforce that policy against violation by a receiving party.

As data moves across trusted boundaries from on-premises storage devicesof a user environment to a remote data storage service, the user can beprovided with a mechanism to enable the categorizations and policies tomigrate and live with the data. A policy migration service can be usedto enforce existing policies in other environments, such as a cloudenvironment, to ensure compliance, security, and IT governance. Such aservice can also ensure polices move with the data as the data movesoutside of the cloud environment. In addition to policy migration, achain of custody of the data can be maintained and migrated with data aswell. A chain of custody can include a detailed audit log for the data,as well as of any policies or tags applied to the data. The resourceprovider environment can be configured to import and export the chain ofcustody along with the policies that apply to the data.

Various other such functions can be used as well within the scope of thevarious embodiments as would be apparent to one of ordinary skill in theart in light of the teachings and suggestions contained herein.

FIG. 1 illustrates an example environment 100 in which aspects of thevarious embodiments can be implemented. In this example a user is ableto utilize a client device 102 to submit requests across at least onenetwork 104 to a resource provider environment 106. The client devicecan include any appropriate electronic device operable to send andreceive requests, messages, or other such information over anappropriate network and convey information back to a user of the device.Examples of such client devices include personal computers, tabletcomputers, smart phones, notebook computers, and the like. The at leastone network 104 can include any appropriate network, including anintranet, the Internet, a cellular network, a local area network (LAN),or any other such network or combination, and communication over thenetwork can be enabled via wired and/or wireless connections. Theresource provider environment 106 can include any appropriate componentsfor receiving requests and returning information or performing actionsin response to those requests. As an example, the provider environmentmight include Web servers and/or application servers for receiving andprocessing requests, then returning data, Web pages, video, audio, orother such content or information in response to the request.

In various embodiments, the provider environment may include varioustypes of electronic resources that can be utilized by multiple users fora variety of different purposes. In at least some embodiments, all or aportion of a given resource or set of resources might be allocated to aparticular user or allocated for a particular task, for at least adetermined period of time. The sharing of these multi-tenant resourcesfrom a provider environment is often referred to as resource sharing,Web services, or “cloud computing,” among other such terms and dependingupon the specific environment and/or implementation. In this example theprovider environment includes a plurality of electronic resources 114 ofone or more types. These types can include, for example, applicationservers operable to process instructions provided by a user or databaseservers operable to process data stored in one or more data stores 116in response to a user request. As known for such purposes, the user canalso reserve at least a portion of the data storage in a given datastore. Methods for enabling a user to reserve various resources andresource instances are well known in the art, such that detaileddescription of the entire process, and explanation of all possiblecomponents, will not be discussed in detail herein.

In at least some embodiments, a user wanting to utilize a portion of theresources 114 can submit a request that is received to an interfacelayer 108 of the provider environment 106. The interface layer caninclude application programming interfaces (APIs) or other exposedinterfaces enabling a user to submit requests to the providerenvironment. The interface layer 108 in this example can also includeother components as well, such as at least one Web server, routingcomponents, load balancers, and the like. When a request to provision aresource is received to the interface layer 108, information for therequest can be directed to a resource manager, authorization manager110, or other such system, service, or component configured to manageuser accounts and information. A component such as a resource managercan also handle tasks such as resource provisioning and usage, and othersuch aspects. An authorization manager 110 receiving information for therequest can perform tasks such as to authenticate an identity of theuser submitting the request, as well as to determine whether that userhas an existing account with the resource provider, where the accountdata may be stored in at least one account data store 112 or other suchrepository in the provider environment. A user can provide any ofvarious types of credentials in order to authenticate an identity of theuser to the provider. These credentials can include, for example, ausername and password pair, biometric data, a digital signature, orother such information. The provider can validate this informationagainst information stored for the user in the account data store 112.If the user has an account with the appropriate permissions, status,etc., information can be passed to the resource manager, which candetermine whether there are adequate resources available to suit theuser's request, and if so can provision the resources or otherwise grantaccess to the corresponding portion of those resources for use by theuser for an amount specified by the request. This amount can include,for example, capacity to process a single request or perform a singletask, a specified period of time, or a recurring/renewable period, amongother such values. If the user does not have a valid account with theprovider, the user account does not enable access to the type ofresources specified in the request, or another such reason is preventingthe user from obtaining access to such resources, a communication can besent to the user to enable the user to create or modify an account, orchange the resources specified in the request, among other such options.

Once the user is authenticated, the account verified, and the resourcesallocated, the user can utilize the allocated resource(s) for thespecified capacity, amount of data transfer, period of time, or othersuch value. In at least some embodiments, a user might provide a sessiontoken or other such credentials with subsequent requests in order toenable those requests to be processed on that user session. The user canreceive a resource identifier, specific address, or other suchinformation that can enable the client device 102 to communicate with anallocated resource without having to communicate with the resourcemanager, at least until such time as a relevant aspect of the useraccount changes, the user is no longer granted access to the resource,or another such aspect changes.

The resource manager (or another such system or service) in this examplecan also function as a virtual layer of hardware and software componentsthat handles control functions in addition to management actions, as mayinclude provisioning, scaling, replication, etc. The resource managercan utilize dedicated APIs in the interface layer 108, where each APIcan be provided to receive requests for at least one specific action tobe performed with respect to the data environment, such as to provision,scale, clone, or hibernate an instance. Upon receiving a request to oneof the APIs, a Web services portion of the interface layer can parse orotherwise analyze the request to determine the steps or actions neededto act on or process the call. For example, a Web service call might bereceived that includes a request to create a data repository.

An interface layer 108 in at least one embodiment includes a scalableset of customer-facing servers that can provide the various APIs andreturn the appropriate responses based on the API specifications. Theinterface layer also can include at least one API service layer that inone embodiment consists of stateless, replicated servers which processthe externally-facing customer APIs. The interface layer can beresponsible for Web service front end features such as authenticatingcustomers based on credentials, authorizing the customer, throttlingcustomer requests to the API servers, validating user input, andmarshalling or unmarshalling requests and responses. The API layer alsocan be responsible for reading and writing database configuration datato/from the administration data store, in response to the API calls. Inmany embodiments, the Web services layer and/or API service layer willbe the only externally visible component, or the only component that isvisible to, and accessible by, customers of the control service. Theservers of the Web services layer can be stateless and scaledhorizontally as known in the art. API servers, as well as the persistentdata store, can be spread across multiple data centers in a region, forexample, such that the servers are resilient to single data centerfailures.

As mentioned, a customer of such a resource environment might have datathat is stored within on-premises data storage devices, such as the datastores 210 illustrated in the user environment 202 of the examplesituation 200 of FIG. 2. The data is stored within a trusted boundary204 of the customer environment, and can be processed using variousresources 208 (e.g., physical or virtual servers) of the userenvironment 202. The data can be managed using various policies that canbe administered by a policy manager 212 and stored in a policy database214 or other such location. A policy manager in general can refer to asystem, service, or component that performs tasks such as creatingpolicies, associating policies with objects, maintaining theassociations, providing access to policies, and other such tasks. Userscan write policies such as predicate-based policies and lifecycle-basedpolicies, wherein specific actions will be performed for objects withcertain tags according to certain predicate-based policies (differentpolicies can apply for different actions) and wherein a determinedaction will be performed for all objects with a specific tag forlifecycle-based policies.

Requests for access to the data or transmissions including portions ofthe data can be sent through an interface layer 206, such as thosediscussed above with respect to FIG. 1. It should be noted thatreference numbers may be carried over between figures for similarelements for purposes of simplicity of explanation, but such usageshould not be interpreted as a limitation on the scope of the variousembodiments unless otherwise specifically stated. The policies used tomanage data in the user environment 202 are often enforced at the levelof the storage devices themselves. If the user wants at least some ofthe data in the data stores 210 to be migrated to data stores 116 in theresource provider environment 106, whether for redundancy or alternativestorage options, the user will have no way under conventional approachesto migrate the policies with the data. As mentioned, a resource providerenvironment typically will have no way of mapping the user policies tothe policies supported in the resource environment. Further, theresource provider environment may not have any way of ensuringenforcement of the user policies in the resource environment or afterexport of the data to a third party.

Accordingly, approaches in accordance with various embodiments canenable a user to apply one or more tags to a particular set, group, orcollection of data, or a data object or data file, where those tags canbe associated with policies and be immutably tied to the particular datathat is migrated to the provider environment 106. These tags can beautomatically generated by software in the user environment, such as bya policy import/export engine 226 or similar component that can performtasks such as to monitor the exportation of data, or be contacted in theevent of an export, etc., and cause the appropriate tag(s) to beapplied. As mentioned, a tag can be an instance of metadata, a property,or another such indicator that can be mutably or immutably tied to adata object. These tags can be tied to a data object throughout itslifetime, even as the data is moved between locations within anenvironment or between environments (i.e., into the cloud), where thedata is transmitted across at least one trust boundary. The tags can beautomatically generated or assigned based on predicates (i.e., filename,date, other metadata) that is applied to the files and/or policiesduring communication to the remote storage system.

A policy import/export engine (or separate import and export engines)can refer generally to one or more systems, services, or components thatare configured to perform tasks such as the importing and exporting ofpolicies, as well as determining whether those policies are able to beimported or exported, determining any conflicts, verifying ownership oraccess to various policies for import/export purposes, and the like. Insome embodiments the tags are assigned based upon predicates, such asfilename, date, or other metadata, that is applied to the files and/orpolicies during transmission of the data to the resource providerenvironment 106. In other embodiments, an envelope can be generated forthe transmission of data, where that envelop describes the policy to beassociated with the data. The envelope can then be transmitted with thedata, such as may “include” or “wrap” the data in the envelope, forreceipt and processing by the resource provider environment. As will bediscussed subsequently, the tags and/or envelope can then be processedby a component such as a policy import/export engine 220 of the resourceenvironment. The policy import/export engine 220 can determine the“cloud” policies, or policies of the resource provider environment 106,that apply to the bucket or other location for which the user data is tobe stored, and if the data and/or user policies violate a policyassociated with the bucket then a PUT or similar operation can bedenied. In at least some embodiments, the policy import/export engine220 can work with a policy manager 228, or other such component, system,or service that manages policies on behalf of the resource providerenvironment 106. In some embodiments the policy manager works with theauthorization manager 110 or other such components to determineauthorizations of the user in addition to policies to be applied to suchusage. This can include, for example, which policies to apply for aspecific task to be performed on behalf of a user. In some embodiments,federated identities can be used, as may be provided by various thirdparties, in order to determine the appropriate authorizations, policies,etc.

The usage of tags with data enables a user to utilize policy-basedmanagement capabilities to curate their data as it moves between thecustomer environment 202 and the resource provider environment 106. Theability to tag data enables the user to be able to track, identify,and/or categorize the data, as well as to understand how that data isbeing used. A users can then leverage this data classification and tagapproach tags to write and/or select polices to be used in managing thedata within the customer environment 202, within the resource providerenvironment 106, and at other locations that might obtain access to thedata. Once a policy is applied using these tags, the policy should beautomatically enforced in the environment or on the storage platformwhere the data resides. The ability to categorize data enables datamanagement based on factors such as compliance requirements, informationtechnology (IT) governance, and security policies that apply for a givenuser (i.e., enterprise). For example, a user can categorize a set ofdata as “log” data. The user can then manage all data that falls withinthis category using a specified set of policies. Data categorized in aseparate category, such as “financial critical” data, may be subject toa different set of management policies, as may be specified by contractor otherwise. Users today rely on their on-premises storage devices 208,210 to support policy enforcement and management. As users move theirdata to resource provider environments 106 (and back), the approachespresented herein can provide a way for the user to ensure the specifieddata classifications and policies move with the data.

Users can be provided with the ability to tag and classify data usingcustom tags. Any given object stored in the resource providerenvironment 106 can have one or more custom tags, which can be managedby a data manager 218 and determined using a policy import/export engineor other such component(s). In various embodiments, data object tags canbe of two types: mutable and immutable. Mutable tags can be changed atany time during the lifecycle of a data object, with access beingcontrolled (i.e., only federated identities or other authorizedidentities can have access to edit or change a tag). Immutable tagscannot be removed from a data object or changed once applied to a dataobject. Object tag access is controlled by the data manager 218, andsimilar components in other environments, such that only authorizedusers or groups can edit tags. The ability to enable users to tag andclassify data is important in at least some embodiments as it can beimpossible, or at least difficult, for the resource provider to attemptto predict the different ways customers would want to author datamanagement policies.

In order to provide the necessary flexibility for users, managementpolicies can be able to be specified for individual data objects. In theexample of data on a file system, users manage permissions and metadataon individual files. Managing individual files, however, becomesincreasingly difficult as the number of files grows. Similarly, usersmay can be provided with the ability to write data management policiesbased on the data classifications (tags) specified at the object level.Such ability enables users to exercise more control and better managetheir data in the resource provider environment 106, as may simplifydata management. An example includes the writing of a cross-regionreplication policy based on a custom tag for sensitive user data.However, having policies on custom object level tags may not besufficient in at least some embodiments. In order to provide a trulycustomizable policy engine 220, the provider environment 106 can, in atleast some embodiments, also support the incorporation ofpredicate-based triggers. These triggers can include actions such asGET, PUT, and DELETE, for example, that a user can perform on aspecified data object. The ability to pivot data management policies onpredicates enables customers to write much more effective policies tocontrol on their data. The policy engine 220 can combine object-levelcustom tags, custom polices, and predicate-based triggers to enablepolicy-driven data management. Example policies could specify to “onlyallow GET operations on objects tagged with ‘legal hold’ if the useraccessing the data object is part of a specified group,” for example, or“for objects tagged with ‘EU’ only allow writing to buckets within EUregions,” among other such options.

Tags can also be used to track information across the lifecycle of adata object. If a data object is copied and/or moved to a specifiedlocation, information such as the classification, applied tags, and therespective policies for that data object need to move with the dataobject. Keeping this information together with the data object ensuresthat information can be tracked across the lifecycle even when datamoves across trust boundaries 204, 216. For example, an object can bemoved to the resource provider environment 106, then copied to adifferent bucket after applying some transform by creating a secondarydata object. The category (i.e., tag) for this data object will need tobe copied as well as the policy, even though the second data object maybe a copy. Such requirements enable customers to follow the informationacross its lifecycle and ensure that the appropriate policies areapplied. The editing or removal of a policy can be performed only by auser who has explicit permission to edit object policy, and this changecan be logged appropriately.

The policy import/export engine 220 can provide access control to managepermissions for the adding, editing, and removal of tags and policiesfor data object stored in the data stores 116 of the resource providerenvironment 106. The engine in at least some embodiments can ensure thatonly authorized users have the ability to change policies on a dataobject, and that any changes are documented and/or logged for futurereference. Various embodiments can also attempt to simplify the creationand management of policy, as users may need the ability to controlpolicies at the object level, but creating a separate policy for everysingle object will generally not be a manageable solution in at leastmost circumstances. Instead, the ability to combine a predicate with atag can enable users to create policies and apply them to specific dataobjects.

As the data moves across the trusted boundaries 204, 216 from theon-premises storage devices 210 of the user environment 202 to the datastorage resources 116 of the resource provider environment 106, theusers will need a way to transfer the applicable data categorizationsand policies as well. An approach in accordance with various embodimentscan utilize a policy migration service, or other such system, service,or component, to enforce existing policies by the resources 114 of theresource provider environment to ensure compliance, security, and ITgovernance, among other such aspects. Such a service can also ensurepolices move with data as the data object(s) moves outside of theresource provider environment. While the functionality will be describedas being provided, at least in part, by the policy import/export engine220, it should be understood that alternative components can be used toprovide such a service, as may be part of, or separate from, theresource provider environment. With hybrid storage deployments, users(or customers of the resource provider) may freely move their databetween the on-premises storage devices 210 and the data stores 116 ofthe resource provider environment 106. As users use policies to manageand curate their data on-premises, these policies need to move with thedata to the cloud or other such environments. The same restrictionapplies as data is moved across buckets and otherwise within theresource provider environment 106. The policy import/export engine 220enables customers to specify the existing policies along with a dataobject as the data object moves across trusted boundaries 204, 216 tothe cloud. This also applies to data moving out of the resource providerenvironment 106, where the policies that apply to the data object againneed to move with the object. Additionally, the resource providerenvironment 106 can ensure that the policy being specified by the useris secure and has not been improperly modified. Such functionalityprovides at least some protection against ‘man in the middle attacks,’as well as a way for the user to trust the policy after the policy hasbeen provided to the resource provider environment 106. An example wouldbe to ‘sign’ the policy and later validate the signature to ensure theproper policy has been applied to the object. In order to enablepolicies to be specified and imported into various embodiments, it isdesirable in at least some embodiments to standardize the tags,policies, and classifications, or at least ensure that the format forspecifying the policy for a given object is easy to specify andpublically documented. Furthermore, the resource provider environment106 should be configured to be able to handle situations where thepolicy specified with an object cannot be applied, and place a hold onthat data or perform another appropriate action.

In addition to policy migration, in at least some embodiments the chainof custody of the data object is migrated with data as well. The chainof custody in some embodiments includes a detailed audit log/trail ofactions performed on the data, as well as tags and policies that governhow the data is managed on the storage platform. The resource providerenvironment can thus provide a way to import and export the chain ofcustody along with the policies that apply to the data. Most compliancemandates, such as payment card industry (PCI) and health insuranceportability and accountability act (HIPPA) mandates, require enterprisesto maintain immutable logs of all actions performed on sensitive datafor long periods of time. The detailed audit log of all actions,policies, tags, and interactions forming the ‘chain of custody’ for adata object can help to track the information lifecycle for the object.According to one International Data Corporation (IDC) study, it is notuncommon to see three to twenty or more copies of production data forbackup cycles, business continuance, development test, and data mining.Considering an object that is moved to the resource provider environment106 in bucket ‘A’ from an on-premises storage device 210 of the userenvironment 202, that data object can be copied to a secondary bucket‘B’ in the resource environment 106, and the policies on the data objectcan be edited. In order to maintain the ‘chain of custody’ for this dataobject, a detailed log of all actions on the object as well as thepolicies that govern the object need to be maintained. Looking at thedata object in bucket ‘B’, an auditor should be able to track allactions performed on the object in the on-premises storage appliance, inbucket ‘A,’ as well as bucket ‘B’. These actions include changes to thetags and policies applied to the data.

In addition to ensuring that the relevant policy migrates with a dataobject as the data object moves to the cloud, the resource providerenvironment 106 can also ensure that the chain of custody migrates withthe data as well. A data object may live on an on-premises storagedevice 210 for years. The audit log and history of all actions performedon the data object and its policies can be lost as this data moves tothe resource provider environment 106. The resources 114 of the resourceprovider environment thus need to provide users with a way to securelyimport the audit log and history for the data, in order to maintain thechain of custody for the data. This process also applies for moving adata object out of the resource provider environment. The resourceprovider environment can provide users a way to obtain the policies, aswell as the audit logs, in a standardized format. As the chain ofcustody is handed over to the resource provider environment from trustedpartners, the resource provider environment 106 should be able tovalidate that the chain of custody is secure and has not been tamperedwith.

In addition to trusted partners, the data may be passed from theresource provider environment to a third party environment 302associated with a third party, as illustrated in the example situation300 of FIG. 3. In this example, the user may want to enable the thirdparty to obtain a copy of a data object that was originally stored inthe on-premises storage devices 210 of the user environment 202. Asdiscussed, the data object could have been transferred to the datastorage resources 116 of the resource provider environment, along withthe classifications, tags, policies, and chain of custody in at leastsome embodiments. As discussed, the policy import/export engine 220 (oranother appropriate component, system, or service) can determine theappropriate tags, policies, classifications, and other appropriateinformation for a data object, and cause that information to be storedto an appropriate location (such as a policy data store 222 or audit logdata store 224) while remaining associated with the received and storeddata object. The ability to utilize these policies enables the resourceprovider environment to function as a trusted intermediary for policies.In the event that a data object from the user, stored in the resourceprovider environment, is to be transferred to the third partyenvironment 302, the policy associated with the data object by the usercan be enforced against violation by the third party by theimport/export engine, or other appropriate component(s), of the resourceprovider environment 106. This can include policies to, for example, nottransfer the data object outside of a specified country, even if thethird party would normally perform such an export. In addition to theconventional resources 308 and interface layer 304 of the third partyenvironment 302, the third party environment can include a policymanager 306, policy import/export engine 310, and/or other suchcomponent for performing tasks such as receiving and managing thepolicies, tags, chain of custody, and other information associated witha received data object in at least some embodiments.

FIG. 4A illustrates a first portion 400 of an example process forcausing a policy to be maintained with a data object that can beutilized in accordance with various embodiments. It should be understoodthat for this and other processes discussed herein that additional,fewer, or alternative steps can be performed in similar or alternativesteps, or in parallel, within the scope of the various embodimentsunless otherwise stated. In this example, in which the portion occurs ina user or customer environment, data to be stored locally by anon-premises storage device is determined 402. This can be a manualdetermination or automatic determination, as may be determined by anapplication executing in the user environment. A classification for thedata can also be determined 404. The classification can be determinedautomatically or based upon predicates for the data, such as may bebased in part upon the filename, date, or other metadata, that isapplied to the data object (or policies) during storage and/ortransmission of the data, among other such options. The predicate can bedefined as one or more actions that can be taken on a data object, suchas a READ, WRITE, PUT, or GET, among other such actions. Based at leastin part upon the classification of the data, one or more tags can beapplied 406 to the data. Each tag can function as an identifier thatpoints to, is indicated by, or is otherwise associated with a policythat governs who should have access to the data, where and how accessshould be granted, what type of access should be granted, how the datacan be used, and/or other such actions. Each policy can be written usinga standardized policy language (or otherwise standardized), for example,that can be understood by various environments or services receiving thepolicy. The policy can then be associated with the data, either throughan associated maintained in the user environment or by inserting thepolicy into the data object with the tag, among other such options. Insome embodiments a policy server can be contacted using the informationfrom the tag to determine the appropriate policy, which can then beobtained from a central policy repository or other such location. As thedata is stored locally, chain of custody data can be maintained 408 forthe data. The chain of custody can include records for any changesrelated to the data, such as a change in tag, policy, or classification,access to the data, movement of the data, etc. The ability to supportsuch determinations can be performed natively in the user environment,as well as other environments, such that once the data is classified thedata can be handled appropriately, and automatically, without userintervention.

A request (or instruction) to transmit the data for storage by a remotedata storage service (or other resource provider environment) can bereceived 410. This can be from within, or from outside, the userenvironment. If received from outside the environment, an authorizationor other such procedure may be performed before initiating the transfer.If it is determined that the data can be transferred for storage, thedata can be provided 412 along with the corresponding tag, policy, andchain of custody. Other information such as classification andpredicates can also be provided in some embodiments. This informationcan be embedded in the data object in some embodiments, while in otherembodiments the data object may be transferred in a wrapper or“envelope” that includes the policy and chain of custody, with the tagbeing included in a header of the data object or other such location. Insome embodiments the policy may not be included, with the recipienteither already having a copy of the standardized policy or being able torequest a copy if not already stored. In any case, the data objectshould be configured such that the policy moves with the data object, inat least some embodiments, such that the policy does not get “lost” asthe data is moved or stored in various locations. Further, the chain ofcustody or audit log should remain with the data object as well. As longas the entity storing the data is trusted, the chain of custody andpolicy should ensure the integrity and proper use of the data, to theextent practical in such a system. Once the data is transferred toanother party the ability to enforce the policy on that party can belimited as discussed elsewhere herein.

FIG. 4B illustrates a second portion 420 of the example process that canbe performed in accordance with various embodiments. In this portion,which is performed by a data storage service or resource providerenvironment, for example, a data object is received 422 that includesthe appropriate data, as well as at least a tag, a policy, and a chainof custody. As discussed, portions of this information may be containedin an envelope used to wrap the data object during transmission, andother information may be included as well, such as classification orpredicate data, among other such options. The data object can be parsed424, such as by a policy import/export engine, in order to extract thepolicy and chain of custody information. Before performing any furtheraction, support for the policy in the environment or service can beverified 426. If the service or environment, or at least a bucket orrepository to receive the data, is not able to support or enforce thepolicy, the data object may not be stored by the environment and anerror message or other notification sent to the owner of the data (i.e.,in the user environment). This can include ensuring that the policy forthe data object does not conflict with any other policy in the resourceenvironment. If there are multiple policies, such as a bucket policy,access control list policy, and a user policy, for example, the dataobject policy must not conflict with any of those policies. If thepolicy is supported and any other criteria are met, the policy can bestored 428, the data can be stored 430, the chain of custody data stored432, and the tag(s) stored 432 in the resource environment. Thesestoring steps are shown in parallel as the information can be stored inthe same or different locations, such as where the policy is stored to apolicy repository to be managed by a policy enforcement engine or othersuch component or system. The information can also be stored to a singlerepository in other embodiments. Where the information is storedseparately, the relationships between the various information can bemaintained as discussed elsewhere herein.

FIG. 4C illustrates a third portion 440 of the example process that canbe performed in accordance with various embodiments. In this portion,which also can be performed by a data storage service or resourceprovider environment, for example, a request for at least a portion ofthe data is received 442 to the resource provider environment. Adetermination can be made 444 (in at least some embodiments) as towhether the requestor is authorized to access and/or receive the data(or perform another such action). If not, the request can be denied 446.If the request is granted, the chain of custody information can beupdated 448. As mentioned, a chain of custody can be maintained for allactions on the policies, tags, and objects, and needs to be immutable inat least some embodiments. While the timing of the update can vary, inat least some embodiments the updating will occur before the data istransmitted as the chain of custody information will travel with thedata object. In response to the request, a data object can be generated450, or located if the data object is stored with all the necessaryinformation in the data storage service. As discussed, this can involveworking with a policy enforcement engine, policy import/export engine,or other such component(s) to ensure that the appropriate policy andother information is located and attached to the data. The data objectcan then be transmitted 452 to the requestor. As mentioned, in someembodiments information about the requesting party (if not the user) canbe determined to ensure that the requestor is trusted to enforce thepolicy on the data.

In some embodiments, the transmission of the data object may not providethe recipient with unlimited access to the data. The recipient mighthave access rights to the data, but may be limited in the type of accessor use of the data. Accordingly, FIG. 5 illustrates an example process500 wherein the access to the data is restricted even when the recipienthas a copy of the data object. In this example, a data object isreceived 502 where the data is encrypted, or received in ciphertextform. In some embodiments all of the contents of the data object may beencrypted, while in other embodiments only a portion of the data objectmay be encrypted, such as the data payload portion and/or chain ofcustody, while the other information (in an envelope or otherwise)remains unencrypted. This enables the tag and/or policy data to bedetermined, which can help the recipient to determine actions that canbe taken on the data or any access or use restrictions on the data,among other such determinations. The data, in ciphertext form, can thenbe stored 504 to the receiving environment. Subsequently, a request foraccess to the data can be received 506 from an application or other suchsource in the receiving environment. Using the tag for the data, theappropriate policy can be determined 508 for access to the data. Atemporary credential (e.g., a key that expires after a period of time)can be requested 510, such as from the resource provider environment,the user environment, or a key management service, among other suchoptions. A determination can be made 512 as to whether or not thereceiving environment and/or requesting application complies with thepolicy. In at least some embodiments the application must provideinformation regarding the intended use of the data. The user environmentand/or source of the temporary key can then determine, based at least inpart upon the intended use, geographical data, authorization data,and/or other such information, whether the use complies with the policysuch that the temporary credential should be issued. The criteria forissuing the credential and allowing the access also can be governed by apolicy that operates at a different functional level than the dataobject policy. If the requested use and/or access does not comply withthe policy, the request can be denied 514 (or never submitted in thecase where the receiving environment can perform the determination). Ifthe intended use and access complies with the policy, the temporarycredential can be received 516. In some embodiments the temporarycredential can be received to an intermediate application or componentin the receiving environment that is able to unwrap or otherwise obtainthe appropriate temporary credential without exposing the credential tothe rest of the receiving environment. The intermediate application canthen decrypt 518 at least a portion of the data using the temporarycredential, and then provide 520 the decrypted data to the requestingapplication. This can result in, for example, a user being able to playa media file through a media player application when the currentlocation and/or use satisfies the policy. If the current location or usechanges so as to no longer comply with the policy, a temporary passwordwill not be received and the media player will be unable to receive thedecrypted data for purposes of playback. While a user receiving thedecrypted data can potentially capture the decrypted data such thatdecrypting of the data object is no longer necessary, such usage stillprovides some level of control over the usage of the content andenforcement of the policies. Because the temporary password is onlyprovided to a trusted recipient, the risk of unintended use of the datacan be minimized. In some embodiments the temporary credential expiresafter a period of time, while in other embodiments a message can be sentwhen the data is done being provided (such as when a movie or song isdone streaming) whereby that credential is no longer valid and a newtemporary password must be obtained. The data can be stored inciphertext, and not accessed when the policy is not being complied withand a temporary credential cannot be received. If the data objectsubsequently complies with the policy again, a temporary password can beissued (except in situations where the intermediate non-compliance, asmay be reflected in the chain of custody, prevents such access). Itshould be understood, however, that in some embodiments the media player(or other such application) can request and obtain the temporarycredential for playback or access without going through an intermediateapplication as discussed above.

In some embodiments, the providing of data in cleartext or ciphertextcan depend at least in part upon the environment of the requestor. Forexample, if the data is stored in a resource provider environment andthe request is received from within the resource provider environment,such that the data will not pass beyond a trusted boundary, the data canbe decrypted and provided in cleartext. If the request will cause thedata to pass beyond the trusted boundary, the data can be sent inciphertext.

As mentioned, it can be desirable in at least some embodiments to createa standard for the tagging and creation of policies, with standardizedresource characteristics, etc. There may be various levels of complianceor support, where a requestor must have the appropriate level in orderto be able to receive or access the data, or perform certain actionswith respect to the data. Further, the policies provided might not be abound on the types of use permitted, but a restriction as to certainprohibited uses. For example, the data might be able to be used for anypurpose within a trust boundary except to print a copy of the data orgenerate a copy of the data. Further, the data might not be able to becopied to any location that does not support the policies. There alsocan be different policies at different levels. For example, there can bepolicy at the account level, a different policy at the bucket level, andyet another applicable policy at the data object level. As mentioned,there can be unique policies applied to each object, or policies canapply to various classifications of objects or objects including asimilar tag. Further, each object can store its own policy or policiescan be maintained in a central policy repository, among other suchoptions.

As mentioned, there can be various triggers for a data object as well.There may be various tags defined for a data object, with eachspecifying a different policy for a different type of operation. Whendoing a PUT or GET operation, for example, the requestor can specify apolicy and one or more triggers. When storing the data object to aresource provider environment, for example, the triggers can be storedwith the tags and policies. While a tag is generally an identifier for apolicy (or the target of a policy), a trigger refers to an action thatcan be taken on a data object. Thus, it can be desirable to storeinformation for various triggers as well, as different tags or policiescan apply for different actions. For example, a different set ofcriteria might apply to be able to store data than to read or modifystored data. These can be different triggers, which can each correspondto a different tag and/or policy. In at least some embodiments, asdiscussed above, a requestor has to provide some information about theintent for the data, which can determine which trigger (and thus whichpolicy) to apply. If a user intends to read the data then one triggermight apply, while a user wanting to print out a copy of the data mighthave another trigger apply. There can be standard ways of enabling auser to express what they intend to do with the data, and there can be astandardized way to respond to those requests as well.

In some embodiments, it can be desirable to determine the source of adata object before storing the data object to an environment orperforming another such action. In some embodiments a request to PUT anobject to a data repository in an environment can be signed, using adigital signature, to ensure the source of the data, as well as the factthat that data likely has not been compromised by a “man in the middle”or other intervening party. Particularly for situations such as audit orcompliance determinations, it can be necessary to show that the data wasnot modified between the sender and the recipient. Various types ofauthentication can be used to verify the authenticity of a certificate,as well as that the data signed with that certificate was not modified.When a data object with a tag is received, it can thus be determinedthat the object came from a trusted partner and that the policy can beenforced without concern. Not every aspect of the data object needs tobe signed, as long as the tag (and potentially the audit log) is part ofthe signature in at least some embodiments.

In addition to certain types of access for performing certain types ofactions with respect to the data of the object, different types ofaccess can enable different actions to be performed with respect to thedata object itself. This can include, for example, the ability to modifyor update the tags or policies associated with the data object, specifynew triggers, or perform other such actions. As mentioned previously,any such change can be reflected in the audit log or chain of custody.The access control can be specified by a policy in some embodiments,which can reside at a higher level than the use policy for the dataobject. Different policies at different levels of a level hierarchy canallow different policy criteria and actions to be applied at differentlevels of the hierarchy, such as at the bucket level, account level, oruser level, among other such options.

FIG. 6 illustrates a set of basic components of an example computingdevice 600 that can be utilized to implement aspects of the variousembodiments. In this example, the device includes at least one processor602 for executing instructions that can be stored in a memory device orelement 604. As would be apparent to one of ordinary skill in the art,the device can include many types of memory, data storage orcomputer-readable media, such as a first data storage for programinstructions for execution by the at least one processor 602, the sameor separate storage can be used for images or data, a removable memorycan be available for sharing information with other devices, and anynumber of communication approaches can be available for sharing withother devices. The device may include at least one type of displayelement 606, such as a touch screen, electronic ink (e-ink), organiclight emitting diode (OLED) or liquid crystal display (LCD), althoughdevices such as servers might convey information via other means, suchas through a system of lights and data transmissions. The devicetypically will include one or more networking components 608, such as aport, network interface card, or wireless transceiver that enablescommunication over at least one network. The device can include at leastone input device 610 able to receive conventional input from a user.This conventional input can include, for example, a push button, touchpad, touch screen, wheel, joystick, keyboard, mouse, trackball, keypador any other such device or element whereby a user can input a commandto the device. These I/O devices could even be connected by a wirelessinfrared or Bluetooth or other link as well in some embodiments. In someembodiments, however, such a device might not include any buttons at alland might be controlled only through a combination of visual and audiocommands such that a user can control the device without having to be incontact with the device.

As discussed, different approaches can be implemented in variousenvironments in accordance with the described embodiments. As will beappreciated, although a Web-based environment is used for purposes ofexplanation in several examples presented herein, different environmentsmay be used, as appropriate, to implement various embodiments. Thesystem includes an electronic client device, which can include anyappropriate device operable to send and receive requests, messages orinformation over an appropriate network and convey information back to auser of the device. Examples of such client devices include personalcomputers, cell phones, handheld messaging devices, laptop computers,set-top boxes, personal data assistants, electronic book readers and thelike. The network can include any appropriate network, including anintranet, the Internet, a cellular network, a local area network or anyother such network or combination thereof. Components used for such asystem can depend at least in part upon the type of network and/orenvironment selected. Protocols and components for communicating viasuch a network are well known and will not be discussed herein indetail. Communication over the network can be enabled via wired orwireless connections and combinations thereof. In this example, thenetwork includes the Internet, as the environment includes a Web serverfor receiving requests and serving content in response thereto, althoughfor other networks, an alternative device serving a similar purposecould be used, as would be apparent to one of ordinary skill in the art.

The illustrative environment includes at least one application serverand a data store. It should be understood that there can be severalapplication servers, layers or other elements, processes or components,which may be chained or otherwise configured, which can interact toperform tasks such as obtaining data from an appropriate data store. Asused herein, the term “data store” refers to any device or combinationof devices capable of storing, accessing and retrieving data, which mayinclude any combination and number of data servers, databases, datastorage devices and data storage media, in any standard, distributed orclustered environment. The application server can include anyappropriate hardware and software for integrating with the data store asneeded to execute aspects of one or more applications for the clientdevice and handling a majority of the data access and business logic foran application. The application server provides access control servicesin cooperation with the data store and is able to generate content suchas text, graphics, audio and/or video to be transferred to the user,which may be served to the user by the Web server in the form of HTML,XML or another appropriate structured language in this example. Thehandling of all requests and responses, as well as the delivery ofcontent between the client device and the application server, can behandled by the Web server. It should be understood that the Web andapplication servers are not required and are merely example components,as structured code discussed herein can be executed on any appropriatedevice or host machine as discussed elsewhere herein.

The data store can include several separate data tables, databases orother data storage mechanisms and media for storing data relating to aparticular aspect. For example, the data store illustrated includesmechanisms for storing content (e.g., production data) and userinformation, which can be used to serve content for the production side.The data store is also shown to include a mechanism for storing log orsession data. It should be understood that there can be many otheraspects that may need to be stored in the data store, such as page imageinformation and access rights information, which can be stored in any ofthe above listed mechanisms as appropriate or in additional mechanismsin the data store. The data store is operable, through logic associatedtherewith, to receive instructions from the application server andobtain, update or otherwise process data in response thereto. In oneexample, a user might submit a search request for a certain type ofitem. In this case, the data store might access the user information toverify the identity of the user and can access the catalog detailinformation to obtain information about items of that type. Theinformation can then be returned to the user, such as in a resultslisting on a Web page that the user is able to view via a browser on theuser device. Information for a particular item of interest can be viewedin a dedicated page or window of the browser.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server and typically will include computer-readablemedium storing instructions that, when executed by a processor of theserver, allow the server to perform its intended functions. Suitableimplementations for the operating system and general functionality ofthe servers are known or commercially available and are readilyimplemented by persons having ordinary skill in the art, particularly inlight of the disclosure herein.

The environment in one embodiment is a distributed computing environmentutilizing several computer systems and components that areinterconnected via communication links, using one or more computernetworks or direct connections. However, it will be appreciated by thoseof ordinary skill in the art that such a system could operate equallywell in a system having fewer or a greater number of components than areillustrated. Thus, the depiction of the systems herein should be takenas being illustrative in nature and not limiting to the scope of thedisclosure.

The various embodiments can be further implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers or computing devices which can be used to operate any of anumber of applications. User or client devices can include any of anumber of general purpose personal computers, such as desktop or laptopcomputers running a standard operating system, as well as cellular,wireless and handheld devices running mobile software and capable ofsupporting a number of networking and messaging protocols. Such a systemcan also include a number of workstations running any of a variety ofcommercially-available operating systems and other known applicationsfor purposes such as development and database management. These devicescan also include other electronic devices, such as dummy terminals,thin-clients, gaming systems and other devices capable of communicatingvia a network.

Most embodiments utilize at least one network that would be familiar tothose skilled in the art for supporting communications using any of avariety of commercially-available protocols, such as TCP/IP, FTP, UPnP,NFS, and CIFS. The network can be, for example, a local area network, awide-area network, a virtual private network, the Internet, an intranet,an extranet, a public switched telephone network, an infrared network, awireless network and any combination thereof.

In embodiments utilizing a Web server, the Web server can run any of avariety of server or mid-tier applications, including HTTP servers, FTPservers, CGI servers, data servers, Java servers and businessapplication servers. The server(s) may also be capable of executingprograms or scripts in response requests from user devices, such as byexecuting one or more Web applications that may be implemented as one ormore scripts or programs written in any programming language, such asJava®, C, C # or C++ or any scripting language, such as Perl, Python orTCL, as well as combinations thereof. The server(s) may also includedatabase servers, including without limitation those commerciallyavailable from Oracle®, Microsoft®, Sybase® and IBM® as well asopen-source servers such as MySQL, Postgres, SQLite, MongoDB, and anyother server capable of storing, retrieving and accessing structured orunstructured data. Database servers may include table-based servers,document-based servers, unstructured servers, relational servers,non-relational servers or combinations of these and/or other databaseservers.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (SAN) familiar to those skilled inthe art. Similarly, any necessary files for performing the functionsattributed to the computers, servers or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (CPU), at least one inputdevice (e.g., a mouse, keyboard, controller, touch-sensitive displayelement or keypad) and at least one output device (e.g., a displaydevice, printer or speaker). Such a system may also include one or morestorage devices, such as disk drives, magnetic tape drives, opticalstorage devices and solid-state storage devices such as random accessmemory (RAM) or read-only memory (ROM), as well as removable mediadevices, memory cards, flash cards, etc.

Such devices can also include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device) and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium representing remote, local, fixed and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services or other elementslocated within at least one working memory device, including anoperating system and application programs such as a client applicationor Web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets) or both. Further, connection to other computing devices suchas network input/output devices may be employed.

Storage media and other non-transitory computer readable media forcontaining code, or portions of code, can include any appropriate mediaknown or used in the art, such as but not limited to volatile andnon-volatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data,including RAM, ROM, EEPROM, flash memory or other memory technology,CD-ROM, digital versatile disk (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices or any other medium which can be used to store thedesired information and which can be accessed by a system device. Basedon the disclosure and teachings provided herein, a person of ordinaryskill in the art will appreciate other ways and/or methods to implementthe various embodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

What is claimed is:
 1. A system, comprising at least one processor; andmemory including instructions that, when executed by the at least oneprocessor, cause the system to: receive, in a second environment, a dataobject comprising data and a policy associated with accessing the datawithin a first environment; determine that the policy is supported byand is free of conflicts from other policies of the second environmentand of other environments providing other data objects for the secondenvironment; upon the determining, store the data and the policy to thesecond environment; authenticate a request for data in the data object;determine that access to the data is allowed under the policy in thesecond environment; and generate an updated data object with the data byadding information to an audit log associated with the data in responseto access or actions taken with respect to the data.
 2. The system ofclaim 1, wherein the instructions when executed further cause the systemto: determine an account associated with the request permits validationof the request; and validate a source of the request using storedinformation associated with the account as part of the authentication ofthe request.
 3. The system of claim 1, wherein the instructions whenexecuted further cause the system to: determine a tag associated withthe policy in the first environment; determine that a source of therequest is associated with a group in the second environment; and enablea second tag that is associated with the tag for association with thedata object in the second environment.
 4. The system of claim 1, whereinthe instructions when executed further cause the system to: grant accessto the data after the authentication of the request in the secondenvironment; determine that an action of a source of the request hascaused a violation in the policy; and prevent the source from accessingthe data.
 5. The system of claim 1, wherein the instructions whenexecuted further cause the system to: grant access to the data after theauthentication of the request in the second environment; determine arisk level has changed for a source of the request based in part on thepolicy; and prevent further access to the data.
 6. Acomputer-implemented method, comprising: receiving, in a secondenvironment, a data object comprising data and a policy associated withaccessing the data within a first environment; determining that thepolicy is supported by and is free of conflicts from other policies ofthe second environment and of other environments providing other dataobjects for the second environment; upon the determining, storing thedata and the policy to the second environment; authenticating a requestassociated with the data object; enabling access to the data under thepolicy in the second environment; and adding information to an audit logassociated with the data in response to access or actions taken withrespect to the data.
 7. The computer-implemented method of claim 6,further comprising: determining an account associated with the requestpermits validation of the request; and validating a source of therequest using stored information associated with the account as part ofthe authentication of the request.
 8. The computer-implemented method ofclaim 6, further comprising: determining a tag associated with thepolicy in the first environment; determining that a source of therequest is associated with a group in the second environment; andenabling a second tag that is associated with the tag for associationwith the data object in the second environment.
 9. Thecomputer-implemented method of claim 6, further comprising: grantingaccess to the data after the authentication of the request in the secondenvironment; determining that an action of a source of the request hascaused a violation in the policy; and preventing the source fromaccessing the data.
 10. The computer-implemented method of claim 6,further comprising: granting access to the data after the authenticationof the request in the second environment; determining a risk level haschanged for a source of the request based in part on the policy; andpreventing further access to the data.
 11. The computer-implementedmethod of claim 6, further comprising: receiving the request for atleast a portion of the data in the second environment; determining thata source of the request is authenticated under the policy and separatelyfrom the authenticating of the request associated with the data object;and generating a second data object including the data, the policy, andthe audit log having the information for a destination specified by therequest.
 12. The computer-implemented method of claim 11, furthercomprising: extracting the policy and the audit log from an envelope ofthe data object, the data and a data tag included in the envelope; andgenerating the second data object by placing the data in a secondenvelope and including the policy and the audit log with the informationin the second envelope.
 13. The computer-implemented method of claim 6,further comprising: causing the policy to be stored to a policyrepository managed by a policy engine associated with the secondenvironment; and enforcing the policy in the second environment by thepolicy engine.
 14. The computer-implemented method of claim 6, furthercomprising: determining that the policy is immutable; and preventingmodification of the policy or specification of a new policy for the datain at least the second environment.
 15. The computer-implemented methodof claim 6, further comprising: receiving a request to modify thepolicy, the policy being mutable; determining that a source of therequest is authorized to modify the policy; modifying the policy; andupdating the audit log to reflect the modification of the policy. 16.The computer-implemented method of claim 6, further comprising: storinga set of policies received with the data object, wherein a correspondingpolicy to enforce from the set of policies is based at least in partupon an action to be performed with respect to the data.
 17. Anon-transitory computer-readable storage medium including instructionsthat, when executed by at least one processor of a computer system,cause the computer system to: receive, in a second environment, a dataobject comprising data and a policy associated with accessing the datawithin a first environment; determine that the policy is supported byand is free of conflicts from other policies of the second environmentand of other environments providing other data objects for the secondenvironment; upon the determination being made, store the data and thepolicy to the second environment; authenticate a request associated withthe data object; enable access to the data under the policy in thesecond environment; and add information to an audit log associated withthe data in response to access or actions taken with respect to thedata.
 18. The non-transitory computer-readable storage medium of claim17 including the instructions that, when executed by the at least oneprocessor of the computer system, cause the computer system to:determine an account associated with the request permits validation ofthe request; and validate a source of the request using storedinformation associated with the account as part of the authentication ofthe request.
 19. The non-transitory computer-readable storage medium ofclaim 17 including the instructions that, when executed by the at leastone processor of the computer system, cause the computer system to:determine a tag associated with the policy in the first environment;determine that a source of the request is associated with a group in thesecond environment; and enable a second tag that is associated with thetag for association with the data object in the second environment. 20.The non-transitory computer-readable storage medium of claim 17including the instructions that, when executed by the at least oneprocessor of the computer system, cause the computer system to: grantaccess to the data after the authentication of the request in the secondenvironment; determine a risk level has changed for a source of therequest based in part on the policy; and prevent further access to thedata.